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Abstract 


This document updates the Cryptographic Algorithm Implementation 
Requirements for the Encapsulating Security Payload (ESP) and 
Authentication Header (AH). It also adds usage guidance to help in 
the selection of these algorithms. 


ESP and AH protocols make use of various cryptographic algorithms to 
provide confidentiality and/or data origin authentication to 
protected data communications in the IP Security (IPsec) 
architecture. To ensure interoperability between disparate 
implementations, the IPsec standard specifies a set of mandatory-to- 
implement algorithms. This document specifies the current set of 
mandatory-to-implement algorithms for ESP and AH, specifies 
algorithms that should be implemented because they may be promoted to 
mandatory at some future time, and also recommends against the 
implementation of some obsolete algorithms. Usage guidance is also 
provided to help the user of ESP and AH best achieve their security 
goals through appropriate choices of cryptographic algorithms. 


This document obsoletes RFC 4835. 
Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7321. 
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1. Introduction 


The Encapsulating Security Payload (ESP) [RFC4303] and the 
Authentication Header (AH) [RFC4302] are the mechanisms for applying 
cryptographic protection to data being sent over an IPsec Security 
Association (SA) [RFC4301]. 


To ensure interoperability between disparate implementations, it is 
necessary to specify a set of mandatory-to-implement algorithms. 

This ensures that there is at least one algorithm that all 
implementations will have in common. This document specifies the 
current set of mandatory-to-implement algorithms for ESP and AH, 
specifies algorithms that should be implemented because they may be 
promoted to mandatory at some future time, and also recommends 
against the implementation of some obsolete algorithms. Usage 
guidance is also provided to help the user of ESP and AH best achieve 
their security goals through appropriate choices of mechanisms. 


The nature of cryptography is that new algorithms surface 
continuously and existing algorithms are continuously attacked. An 
algorithm believed to be strong today may be demonstrated to be weak 
tomorrow. Given this, the choice of mandatory-to-implement algorithm 
should be conservative so as to minimize the likelihood of it being 
compromised quickly. Thought should also be given to performance 
considerations, as many uses of IPsec will be in environments where 
performance is a concern. 


The ESP and AH mandatory-to-implement algorithm(s) may need to change 
over time to adapt to new developments in cryptography. For this 
reason, the specification of the mandatory-to-implement algorithms is 
not included in the main IPsec, ESP, or AH specifications, but is 
instead placed in this document. Ideally, the mandatory-to-implement 
algorithm of tomorrow should already be available in most 
implementations of IPsec by the time it is made mandatory. To 
facilitate this, this document identifies such algorithms, as they 
are known today. There is no guarantee that the algorithms that we 
predict will be mandatory in the future will actually be so. All 
algorithms known today are subject to cryptographic attack and may be 
broken in the future. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 
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We define some additional keywords here: 


MUST- This term means the same as MUST. However, we expect that at 
some point in the future this algorithm will no longer be a MUST. 


SHOULD+ This term means the same as SHOULD. However, it is likely 
that an algorithm marked as SHOULD+ will be promoted at some 
future time to be a MUST. 


2. Implementation Requirements 


This section specifies the cryptographic algorithms that MUST be 
implemented, and provides guidance about ones that SHOULD or SHOULD 
NOT be implemented. 


In the following sections, all AES modes are for 128-bit AES. 192-bit 
and 256-bit AES MAY be supported for those modes, but the 
requirements here are for 128-bit AES. 


2.1. ESP Authenticated Encryption (Combined Mode Algorithms) 


ESP combined mode algorithms provide both confidentiality and 
authentication services; in cryptographic terms, these are 
authenticated encryption algorithms [RFC5116]. Authenticated 
encryption transforms are listed in the ESP encryption transforms 
IANA registry. 


Requirement Authenticated Encryption Algorithm 
SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] 
MAY AES-CCM [RFC4309] 


2.2. ESP Encryption Algorithms 


Requirement Encryption Algorithm 
MUST NULL [RFC2410] 

MUST AES-CBC [RFC3602] 

MAY AES-CTR [RFC3686] 

MAY TripleDES-CBC [RFC2451] 
MUST NOT DES-CBC [RFC2405] 
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2.3. ESP Authentication Algorithms 


Requirement Authentication Algorithm (notes) 
MUST HMAC-SHA1-96 [RFC2404] 

SHOULD+ AES-GMAC with AES-128 [RFC4543] 
SHOULD AES-XCBC-MAC-96 [RFC3566] 

MAY NULL [RFC4303] 


Note that the requirement level for NULL authentication depends on 
the type of encryption used. When using authenticated encryption 
from Section 2.1, the requirement for NULL encryption is the same as 
the requirement for the authenticated encryption itself. When using 
the encryption from Section 2.2, the requirement for NULL encryption 
is truly "MAY"; see Section 3 for more detail. 


2.4. AH Authentication Algorithms 


The requirements for AH are the same as for ESP Authentication 
Algorithms, except that NULL authentication is inapplicable. 


2.5. Summary of Changes from RFC 4835 


The following is a summary of the changes from RFC 4835. 


Old New 

Requirement Requirement Algorithm (notes) 

MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] 
MAY SHOULD+ AES-GMAC with AES-128 [RFC4543] 

MUST- MAY TripleDES-CBC [RFC2451] 

SHOULD NOT MUST NOT DES-CBC [RFC2405] 

SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566] 

SHOULD MAY AES-CTR [RFC3686] 


3. Usage Guidance 


Since ESP and AH can be used in several different ways, this document 
provides guidance on the best way to utilize these mechanisms. 


ESP can provide confidentiality, data origin authentication, or the 
combination of both of those security services. AH provides only 
data origin authentication. Background information on those security 
services is available [RFC4949]. In the following, we shorten "data 
origin authentication" to "authentication". 
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Providing both confidentiality and authentication offers the best 
security. If confidentiality is not needed, providing authentication 
can still be useful. Confidentiality without authentication is not 
effective [DP0O7] and therefore SHOULD NOT be used. We describe each 
of these cases in more detail below. 


To provide both confidentiality and authentication, an authenticated 
encryption transform from Section 2.1 SHOULD be used in ESP, in 
conjunction with NULL authentication. Alternatively, an ESP 
encryption transform and ESP authentication transform MAY be used 
together. It is NOT RECOMMENDED to use ESP with NULL authentication 
in conjunction with AH; some configurations of this combination of 
services have been shown to be insecure [PD10]. 


To provide authentication without confidentiality, an authentication 
transform MUST be used in either ESP or AH. The IPsec community 
generally prefers ESP with NULL encryption over AH. AH is still 
required in some protocols and operational environments when there 
are security-sensitive options in the IP header, such as source 
routing headers; ESP inherently cannot protect those IP options. It 
is not possible to provide effective confidentiality without 
authentication, because the lack of authentication undermines the 
trustworthiness of encryption [B96] [V02]. Therefore, an encryption 
transform MUST NOT be used with a NULL authentication transform 
(unless the encryption transform is an authenticated encryption 
transform from Section 2.1). 


Triple-DES SHOULD NOT be used in any scenario in which multiple 
gigabytes of data will be encrypted with a single key. As a 64-bit 
block cipher, it leaks information about plaintexts above that 
"birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement 
for the sake of backwards compatibility, but its use is discouraged. 


4. Rationale 


This section explains the principles behind the implementation 
requirements described above. 


The algorithms listed as "MAY implement" are not meant to be endorsed 
over other non-standard alternatives. All of the algorithms that 
appeared in [RFC4835] are included in this document, for the sake of 
continuity. In some cases, these algorithms have moved from being 
"SHOULD implement" to "MAY implement". 
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4.1. Authenticated Encryption 


This document encourages the use of authenticated encryption 
algorithms because they can provide significant efficiency and 
throughput advantages, and the tight binding between authentication 
and encryption can be a security advantage [RFC5116]. 


AES-GCM [RFC4106] brings significant performance benefits [KKGEGD], 
has been incorporated into IPsec recommendations [RFC6379], and has 
emerged as the preferred authenticated encryption method in IPsec and 
other standards. 


4.2. Encryption Transforms 


Since ESP encryption is optional, support for the "NULL" algorithm is 
required to maintain consistency with the way services are 
negotiated. Note that while authentication and encryption can each 
be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10]. 


AES Counter Mode (AES-CTR) is an efficient encryption method, but it 
provides no authentication capability. The AES-GCM authenticated 
encryption method has all of the advantages of AES-CTR, while also 
providing authentication. Thus, this document moves AES-CTR from a 
SHOULD to a MAY. 


The Triple Data Encryption Standard (TDES) is obsolete because of its 
small block size; as with all 64-bit block ciphers, it SHOULD NOT be 
used to encrypt more than one gigabyte of data with a single key 
[M13]. Its key size is smaller than that of the Advanced Encryption 
Standard (AES), while at the same time its performance and efficiency 
are worse. Thus, its use in new implementations is discouraged. 


The Data Encryption Standard (DES) is obsolete because of its small 
key size and small block size. There have been publicly demonstrated 
and open-design special-purpose cracking hardware. Therefore, its 
use is has been changed to MUST NOT in this document. 


4.3. Authentication Transforms 


AES-GMAC provides good security along with performance advantages, 
even over HMAC-MD5. In addition, it uses the same internal 
components as AES-GCM and is easy to implement in a way that shares 
components with that authenticated encryption algorithm. 


The MD5 hash function has been found to not meet its goal of 
collision resistance; it is so weak that its use in digital 
signatures is highly discouraged [RFC6151]. There have been 
theoretical results against HMAC-MD5, but that message authentication 
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code does not seem to have a practical vulnerability. Thus, it may 
not be urgent to remove HMAC-MD5 from the existing protocols. 


SHA-1 has been found to not meet its goal of collision resistance. 
However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is 
believed to be secure. 


HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to provide 
a good security margin, and they perform adequately on many 
platforms. However, these algorithms are not recommended for 
implementation in this document, because HMAC-SHA-1 support is 
widespread and its security is good, AES-GMAC provides good security 
with better performance, and Authenticated Encryption algorithms do 
not need any authentication methods. 


AES-XCBC has not seen widespread deployment, despite being previously 
recommended as a SHOULD+ in RFC 4835. Thus, this document lists it 
only as a SHOULD. 


5. Algorithm Diversity 


When the AES cipher was first adopted, it was decided to continue 
encouraging the implementation of Triple-DES, in order to provide 
algorithm diversity. But the passage of time has eroded the 
viability of Triple-DES as an alternative to AES. As it is a 64-bit 
block cipher, its security is inadequate at high data rates (see 
Section 4.2). Its performance in software and Field-Programmable 
Gate Arrays (FPGAs) is considerably worse than that of AES. Since it 
would not be possible to use Triple-DES as an alternative to AES in 
high data rate environments, or in environments where its performance 
could not keep up the requirements, the rationale of retaining 
Triple-DES to provide algorithm diversity is disappearing. (Of 
course, this does not change the rationale of retaining Triple-DES in 
IPsec implementations for backwards compatibility.) 


Recent discussions in the IETF have started considering how to make 
the selection of a different cipher that could provide algorithm 
diversity in IPsec and other IETF standards. That work is expected 
to take a long time and involve discussions among many participants 
and organizations. 


It is important to bear in mind that it is very unlikely that an 
exploitable flaw will be found in AES (e.g., a flaw that required 
less than a terabyte of known plaintext, when AES is used ina 
conventional mode of operation). The only reason that algorithm 
diversity deserves any consideration is because there would be large 
problems if such a flaw were found. 


McGrew & Hoffman Standards Track [Page 8] 


RFC 7321 Requirements for ESP and AH August 2014 


6. Acknowledgements 


Some of the wording herein was adapted from [RFC4835], the document 
that this one obsoletes. That RFC itself borrows from earlier RFCs, 
notably RFC 4305 and 4307. RFC 4835, RFC 4305, and RFC 4307 were 
authored by Vishwas Manral, Donald Eastlake, and Jeffrey Schiller 
respectively. 


Thanks are due to Wajdi Feghali, Brian Weis, Cheryl Madson, Dan 
Harkins, Paul Wouters, Ran Atkinson, Scott Fluhrer, Tero Kivinen, and 
Valery Smyslov for insightful feedback on this document. 


7. Security Considerations 


The security of a system that uses cryptography depends on both the 
strength of the cryptographic algorithms chosen and the strength of 
the keys used with those algorithms. The security also depends on 
the engineering and administration of the protocol used by the system 
to ensure that there are no non-cryptographic ways to bypass the 
security of the overall system. 


This document concerns itself with the selection of cryptographic 
algorithms for the use of ESP and AH, specifically with the selection 
of mandatory-to-implement algorithms. The algorithms identified in 
this document as "MUST implement" or "SHOULD implement" are not known 
to be broken at the current time, and cryptographic research to date 
leads us to believe that they will likely remain secure into the 
foreseeable future. However, this is not necessarily forever. 
Therefore, we expect that revisions of that document will be issued 
from time to time to reflect the current best practice in this area. 
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